Release 10.1A: OpenEdge Development:
Messaging and ESB

Understanding 4GL-JMS object model

The 4GL-JMS object model is a model wherein a 4GL application interacts with a JMS messaging broker through 4GL objects (persistent procedures) that encapsulate the functionality of JMS sessions and JMS messages. These objects are:

Session objects
Message Consumer objects
Message objects

The 4GL application interacts with the SonicMQ Broker through internal procedures, which perform actions, and user-defined function calls to extract values.

The sections that follow describe Session, Message Consumer, and Message objects, how they correspond to 4GL procedures, and how to create them.

Session objects

A session is a context for sending and receiving messages. OpenEdge supplies three session procedures that the 4GL application uses to interact with JMS. These procedures run persistently to represent a JMS session and its underlying connection:

jms/jmssession.p — For PTP and Pub/Sub messaging.
jms/ptpsession.p — For PTP messaging.
jms/pubsubsession.p — For Pub/Sub messaging.

A single 4GL session can have any number of session procedure instances, each of which creates an underlying JMS connection. These session procedures implement internal procedures that return additional 4GL objects in the form of 4GL persistent procedure handles.

For more information, see the "Managing connections and sessions" section.

Message Consumer objects

The Session object procedures use an internal procedure to create a Message Consumer object. The Message Consumer is a JMS messaging object that performs the following:

Receives messages from a destination.
Receives asynchronous error messages.

The 4GL application must set a message handler procedure in a Message Consumer object by implementing a 4GL internal procedure with a specific signature.

The OpenEdge Adapter for SonicMQ integrates with 4GL event handling. Messages are processed by the Message Consumer when the 4GL is in a WAIT–FOR state or other IO-blocking state. While the application is in such a state, all other UI and non-UI events are handled normally. WAIT–FOR can be called explicitly by the 4GL code. It can also be called through the waitForMessages procedure in the Session object, which works the same for GUI, character, batch, AppServer, and WebSpeed applications.

For more information, see the "Consuming messages" section.

Message objects

A Message object holds the message or information package being sent. The format of the message is determined by the message type. SonicMQ provides several standard JMS message types, plus the XMLMessage and MultipartMessage type. The Session objects have internal procedures that create the messages and represent the JMS connection, Session objects, and Message objects.

For more information, see the "Messages and message types" section.